Upgrading an enterprise resource planning (ERP) system to a new software release often requires upgrading of existing persistent data, for example business object (BO) data, software, customer configurations, application business data, and/or other persistent data associated with a database on the ERP system. The need for upgrading persistent data is common for new software releases often due to changes in a persistency model associated with data instances, for example, changed field value semantics requiring re-assignment of field values and/or new fields or values added to a BO persistency model that must be initialized according to application specific logic. Changes in the persistency model are often due to the need to fulfill new or changed customer requirements, system architectural changes, and/or to react to technology changes. Other reasons to upgrade persistent data include refactoring of the persistency model, software upgrades, and/or changes to a business process model.
Upgrades of persistent data are typically performed during a software upgrade downtime period where the ERP system is taken offline while the upgrade of the persistent data is taking place. Depending on the amount of persistent data to migrate, an upgrade of the persistent data normally requires a considerable amount of time and results in excessive downtime for the ERP system. Excessive downtime impacts an organizations' ability to provide functional business applications and/or necessary data for use by customers. As a result, customers often forego ERP software upgrades and/or establish strict service level agreement (SLA) requirements between the organization and an operational information technology (IT) organization. The SLA normally mandates a maximum permitted downtime for the IT organization to perform persistent data upgrades in order to minimize the impact of persistent data upgrades on ERP systems' business application and/or data usage.
Performing upgrades of persistent data prior to or after the software upgrade downtime period also introduces technical challenges. Upgrading the persistent data after the software upgrade may restrict users to the use of up-to-date/upgraded data that may be limited until the upgrade is complete. Upgrading the persistent data prior to the software upgrade may result in possible conflicts if users change persistent data to be upgraded and often necessitates data locking or multiple re-upgrades of data.